The present invention relates generally to computer systems and more particularly to the management of directory objects in a directory service.
The network computing model, in which intelligent client computers are connected to multiple server computers, is quickly becoming the dominant computing model for enterprises, intranets, and the Internet. At the same time, the network computing model is itself rapidly evolving. As the network technology matures, networks of servers and clients have been and are continuing to replace systems of mainframes and terminals and other computing paradigms, which were once considered more advanced. Cost and productivity are among the primary factors driving the changeover to the client server network model. Relatively inexpensive servers and client computers and off-the shelf software applications are replacing expensive centralized mainframes and cumbersome custom developed software applications.
The network computing model purportedly offers a robust computing environment in which multiple servers provide redundancy to a multitude of clients. However, as the deployment of networks has gained momentum, it has brought its own set of issues. Instead of providing a centralized location from which every aspect of the network can be controlled, computing power is decentralized requiring configuration and control over computers at a number of disparate physical locations. As a result, maintaining the computers and the applications they run at the disparate locations can involve substantial costs.
As the network computing model continues to take hold, computer networks have become an increasingly important tool for users to share access to system resources such as programs, data, printers, and so on. Many attempts have been made to provide a structure for sharing access to resources in a computer network. A particularly important development in structuring access to system resources is the hierarchical directory service. One of the more significant attempts to standardize a directory service is the X.500 directory standard (also known ISO 9594).
Although the X.500 standard offers a basic structure for directory services, it does leave some issues unresolved. Extensibility and providing for a common user interface are among the issues. Adding new resources to the network environment has required making extensive adjustments throughout the network at various client computers and server computers, rather than at a single point. In particular, adding a new resource to the network often requires an administrator to physically go to each computer on the network and reconfigure the computer to enable it to recognize the new resource, e.g., to display attributes of the resource in a user interface. Of course, making all of these adjustments to the system at multiple locations increases the likelihood that an incorrect adjustment will disrupt the operation of the network. In other words, extending the network system has incurred a high cost and created the likelihood that resource extensions would be disruptive to the operation of the network, resulting in lost productivity to the network users.
Moreover, a user interface must be provided for network users to access and view attributes of the network resources. However, in a network with a large number of users, separately reconfiguring the user interface on each user""s computer would be costly and time consuming. Ideally, when a new resource is added to the network and made available to the network users, e.g., through a directory service, all user interfaces should instantly recognize the resource without the need to reconfigure the user interface.
For example, if an administrator wants to add a new scanner resource to the network and make that scanner resource available to all of the network users, information about the scanner should be published in the directory. Thereafter, users could locate the scanner by way of the directory and have the capability to view attributes of the scanner via a user interface. However, if the directory does not support scanner resources, the administrator would have two alternatives: (1) fit the scanner attributes into an existing resource type (alternately referred to as an object class), such as a printer object class; or, (2) define a new object class tailored to scanners. Potentially, alternative (2) may not even be available. In that case, the administrator would have no choice other than to add the new resource as an existing object class.
Under the first alternative, the administrator would add the scanner resource to the directory under the closest available object class, e.g., a printer class. Hence, a user would view the scanner as if it were a printer, even though there may not be complete overlap of attributes. If the new resource closely matches an existing object class, this alternative is satisfactory. However, when no suitable object classes are available for a new resource, this alternative has obvious shortcomings.
Under the second alternative, the administrator would define a new object class to support the scanner resource. Hence, a user should view the scanner as if it were a scanner. But, to view the scanner resource as a scanner, the administrator would have to make extensive changes throughout the network so that each user""s user interface would be able to display all of the attributes of the scanner resource. For example, the administrator would have make changes to the object definitions structure (i.e., the schema) defining the new object class, the computers of all users to provide them with user interface software that recognizes the new object class, and so on.
The cost of such changes are high as is the risk that an inadvertent error made while making the changes will disrupt the operation of the network. Instead, the changes to add the new resource and to add user interface information about the resource should be made from a central location and propagated across the network.
Thus, there is a need for an extensible resource sharing environment in a computing network in which user interface information can be propagated across a computer network.
A network typically comprises a number of workstation clients coupled to one or more servers, such as data servers. Moreover, where the workstation clients share access to data stored by the data servers, such as directory service data, a common data access user interface for all workstation clients is desirable.
The present invention provides an extensible data access user interface by storing user interface information in a display database, preferably part of a directory services database stored on a server, and then coupling that user interface information to the data it will display. To provide the extensible user interface executing on a workstation, a display object that is bound to an object to be displayed is retrieved from the database. Next, the display object is parsed for attributes containing pointers to software modules. The software modules are then fetched by way of the pointers and executed to display aspects of the data object.
Preferably, the pointers contain a pointer to a database of software component modules that can be stored either locally on the workstation, remotely on a server, or both. The user interface application will first check to see if the software module is stored locally on the workstation. If the module is not found locally, then the user interface application will attempt to retrieve the module from the server over the network.
Thereafter, when an administrator wants to modify or extend an interface, for example after a database schema is changed, changes are made to the display database and not locally. When data is then displayed on a workstation, the data""s display information is retrieved from the display database. Accordingly, changes or additions to the user interface software modules or data records are propagated to all workstations that access the display database or software modules.